No-overloading Principle

A C++ programmer said to Rabbi Shammai: " I promise to try object technology if you can explain the secret of objects while standing on one foot. " Rabbi Shammai whacked him on the head with a 10-by-2 ruler. He went to Rabbi Hillel who, standing on one foot, answered: " No overloading. That is the secret of objects. All the rest is commentary. " Some commentary now. The beauty of object technology (OT) is that for all the variations, refinements, codicils, and con-sequences—including fifteen years of the Journal of Object-Oriented Programming articles—everything in the end rests on a single idea: class. A class is an association between some names and some operations, called " features " in Eiffel (and known as " members " in several other languages). In a class P O I N T d e-scribing points in a plane, the names may include x, y, ro, theta, move, and rotate; the features may include operations to return a point's cartesian and polar coordinates, move it by a certain displacement, and rotate it around the origin by a certain angle. The association between names and features is one-to-one: x denotes the operation that returns the horizontal coordinate; ro the one that returns the distance to the center; rotate the rotation operation. Enforcing a one-to-one correspondence keeps everything simple and manageable. It makes the class readable and avoids confusion: if you see a feature name f and do not know what it means, you only have to search until the first feature declaration with that name, and stop there; you know that you have found what you are looking for, and do not need to worry about some competing definition. Easy, simple, and comforting. The rule is simple: Human languages do not quite follow that rule. This can be a source of riddles, as in " time flies like an arrow. " Amusement apart, it is also a source of confusion, not appropriate for a programming or specification language that is designed for precise statement of intent. Within a single syntactic scope such as a class, just choose different names. Why indeed give the same name to two different things? Names are not an endangered species, and there is no tax on keystrokes. Even in Eiffel, where we like giving features clear, meaningful, pro-nounceable names—I have never been able to understand why others use b t n C …